In the early 20th century which is an early stage of development of an automobile, an automobile has been constituted of mechanical parts including an engine supplying motive power, a brake, an accelerator, a steering wheel, a transmission, and a suspension, but has used almost no electrical mechanism except an ignition plug in an engine and a headlight.
However, there has arisen a need for efficiently controlling the engine in case of air pollution, oil crisis, and the like since around 1970s. Thus, an ECU has been started to be used for controlling the engine. The ECU generally includes: an input interface configured to perform, for example, A/D conversion on an input signal from a sensor; a logical computing unit (a microcomputer) configured to process a digital input signal according a predetermined logic; and an output interface configured to convert a result of the processing by the logical computing unit into a signal for starting an actuator.
Nowadays, in addition to the mechanical parts, electronics parts and software account for a significant percentage in a recent automobile, even in not only control systems for the engine, the transmission, and the like, an Anti-lock Braking System (ABS), an Electronic Stability Control (ESC), a power steering but also a windshield wiper control, a security monitoring system, and the like. It is said that development cost of the electronics parts and the software accounts for 25% or 40% in the total development cost. For a hybrid automobile, the development cost accounts for 70%.
Meanwhile, an automobile includes mechanical parts (plants) including a motive power apparatus such as an engine, a power transmission apparatus, a traveling apparatus such as a steering, a brake apparatus, a body system, and the like. Operations of the plants are dynamically determined by programs of 30 to 70 or more electronic control units (ECUs) in response to input from sensors (for speed and the like) and input from a driver (through an accelerator or the like).
Each ECU basically controls the operation of a single plant. For example, software of an engine control unit determines an amount and timing of fuel injection to the engine as well as ignition. From its nature, the software can also increase or decrease the fuel injection amount according to mode in such a luxury automobile that is provided with “sport” mode. The software can also tune the engine revolutions to down-shift timing by automatically performing blipping. In this case, the ECU of the engine and the ECU of the transmission need to operate in cooperation with each other. An integrated vehicle-posture Electronic Stability Control (ESC) system for preventing skids and the like of an automobile further requires cooperation with a braking apparatus such as a brake, and thus ECU software for the system becomes more complicated. Incidentally, from the nature of the software, such an “intervention” function can be eliminated easily.
Meanwhile, in order to fully utilize the performance of the plant and to operate the plant safely, it is important to thoroughly perform operational parameter tuning and tests in a design and development process of the ECU software. Generally, it costs too much and takes a too long time to repeat the tuning and the tests after prototyping of an actual automobile. Thus, a method is strongly desired in which a controller and plants are virtually implemented by a computer before prototyping and are operated at a high speed and accurately for checking their operations. Such ECU simulation is performed by the following four methods: (1) Model-in-the-loop Simulation (MILS) that logically represents an operation of a controller by using such a form as a state machine; (2) Software-in-the loop Simulation (SILS) that introduces some hardware restrictions such as data accuracy to the logic operation of the controller; (3) Virtual Processor-in-the-loop Simulation (V-PILS) that emulates an ECU processor with software fully implemented; and (4) Hardware-in-the-loop Simulation (HILS) in which an ECU board is completely mounted to be connected to a real-time plant simulation. The simulations become closer to a prototype in this order.
MILS and SILS are mainly used in a trial and error phase for obtaining a basic performance of each plant. However, MILS and SILS operate in a different manner from software actually to be provided to the ECU, and thus cannot be used for verifying a product. In contrast, V-PILS uses completed ECU software, and thus is very promising as a method for detecting and solving an undesirable operation (bug) of the software. However, there has been no case where a reproducible operation is achieved. HILS is always implemented for final operation check of the completed ECU board. However, even if a failure is detected, reproducibility of the failure is not guaranteed. Thus, HILS cannot be used for debugging.
The reason why an operation cannot be reproduced in HILS is not that configuration of HILS is not perfect but that ECUs are connected to each other through a network such as a CAN. Generally, a network achieves loose coupling of modules, and thus a slight timing difference among operations of the modules causes the order of data arrival to be changed. As the result, a behavior of the system might vary on the whole. Thus, even if a prototype of an actual automobile is produced, an operation thereof is not expected to be reproduced. The reason is the same as the reason why debugging of a parallel and distributed system is very difficult.
As described above, simply using the HILS configuration, that is, simply using the configuration having the loose coupling of the ECU board and the plant simulators does not achieve operational consistency, even though the components are made operate at a high speed. Achieving consistency of the order of communications is required to achieve the reproducibility of the operations. V-PILS is particularly expected to solve this problem.
FIG. 1 shows a typical V-PILS configuration according to a conventional concept. The configuration includes multiple ECU emulators, multiple plant simulators, and a global scheduler 110 configured to schedule overall operations. It should be understood that FIG. 1 illustrates two ECU emulators 102, 104 and two plant simulators 106, 108 for convenience, but more ECU emulators and plant simulators than illustrated are actually provided.
The ECU emulator 102 includes a processor emulator 102a and a peripheral emulator 102b. Since the ECU emulator 104 has the same configuration, a detailed description of the ECU emulator 104 is omitted.
As for the plant simulator 106, a clock converter 106a is connected thereto. Since the plant simulator 108 has the same configuration, a detailed description of the plant simulator 108 is omitted. For example, the plant simulator 106 is a brake simulator, and the plant simulator 108 is an engine simulator.
Meanwhile, frequencies in FIG. 1 are exemplary typical operating clock speeds. That is, the processor emulator 102a operates at a relatively high clock speed of 80 MHz. In contrast, the plant simulator 106 is a simulator for a physical mechanism, and thus operates at a relatively low speed of 10 KHz.
Next, an operation in the configuration in FIG. 1 will be described by referring to a timing diagram in FIG. 2. Each plant simulator that performs simulation in a fixed-step clock repeats input and output, for example, at 10 KHz, that is, in a time step of 100 μs. The input to the plant simulator is mainly an instruction signal from the controller and the output from the plant simulator is sent to a sensor.
Each peripheral emulator is equivalent to an I/O interface part of the ECU emulator and connects the plant simulator and the processor emulator. The peripheral emulator can be considered to typically (averagely) operate at a resolution of approximately 10 MHz. This speed is higher than that of the plant simulator but lower than that of the processor emulator. The peripheral emulator transmits a pulse signal to the plant simulator.
Each clock converter is arranged between the peripheral emulator and the plant simulator. The clock converter has a function of decreasing the frequency of a clock signal from the peripheral emulator to match the plant simulator and of gradually increasing a frequency of a signal from the plant simulator to match the peripheral emulator.
Each peripheral emulator transmits or receives data to or from the processor emulator in response to a read/write (R/W) request and transmits an interrupt (INT) to the processor emulator. In particular, a function of a network such as the CAN (controller area network) for mutually connecting the processors requires communications among peripherals.
Many of embedded processors operate at approximately 80 to 100 MHz, and thus the time resolution thereof is approximately 10 times higher than that of the peripherals. Each processor performs read and write operations on data from and to a corresponding one of the peripherals and receives an interrupt signal (INT) from the peripheral.
When viewed from one aspect, the peripheral is the center of a system, connecting the plant and the processor with each other, and the processors with each other. The processor performs the R/W operations at the higher time resolution than that of the peripheral. However, when being transmitted to the plant or another processor, a signal for any of the operations is under control of the time resolution of the peripheral. Accordingly, if synchronization processing is performed on sensor data or the like at the time resolution of the peripheral in the simulation system on the whole, the order or processing of I/O data and interrupts is correctly reproduced (minimum synchronization).
Generally, making time intervals of the synchronization shorter can achieve more correct operations. However, this increases overhead of the processing time, and thus increases the total processing time. The minimum synchronization provides an upper limit of the time resolution which does not require any shorter interval.
One of solutions is making the time intervals of synchronization longer up to a greatest common divisor in accordance with the global scheduler 110, as shown in FIG. 3. This can achieve correctness. However, this increases synchronization processing performed at unnecessary timing, and thus increases the overhead of the synchronization processing very much. Thereby, the processing rate of the simulation system is considerably decreased.
If breaks of the processing of the peripheral cannot be explicitly utilized, even the greatest common divisor is difficult to know. Thus, taking a solution of increasing the time resolution further increases the overhead.
In contrast, if the time resolution is made lower, many I/O data pieces and interrupts are included in the same time step. Thus, information on temporal relationship thereamong is lost. This is a state in which simulation is not executed properly, that is, in which the correctness is not achieved. In particular, the order of executing the interrupt processing is very important to operate the software as intended. The few existing V-PILS systems undergo the incorrect simulation state and have a serious problem that the ECU software is not satisfactorily debugged due to the loss of the order information.
Japanese Patent Application Publication No. 2007-11720 has a problem to be solved that a structure of a system simulator is to be changed flexibly while a complicated structure of a system is supported. Japanese Patent Application Publication No. 2007-11720 discloses that a system simulator includes three types of simulators of instruction setting simulators each simulating an operation of a CPU, bus simulators each simulating an operation of a bus, and peripheral simulators each simulating an operation of a peripheral, and is provided with interfaces by which the simulators of each type can refer to and change conditions of the simulators of the other types. However, this conventional technique does not suggest a technique of optimizing synchronization between the peripherals and the CPUs.